<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
  <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  <title>Notes on vil3d image loader</title>
</head><body>
<h2>How to manage the loading process</h2>

<h3>Ideal</h3>
<h4>Use cases</h4>

<ol>

  <li>Filename is in the filesystem namespace. Fileformat identified by file contents.</li>
  <li>Filename implies a set of files. Files are in the filesystem. The
existence of the files triggers full attempt to load files. The file
contents confirm the filetype.</li>
  <li>Filename is URL. The file contents identify format.</li>
  <li>URL
implies a set of files. The existence of the resources triggers full
attempt to load files. The file contents confirm the filetype.</li>
  <li>Filename describes image in entirety</li>
  <li>A loader plugin can take a filestream.</li>
  <li>A loader plugin can take a filename, and recursively issue another load command</li>
  <li>A loader plugin may need to know the filename while taking a filestream?</li>
</ol>

<h4>Design</h4>
<p>Several lists of loaders.</p>

<ol>

  <li>First list decides what to do purely on basis of filename, and includes.

  <ol>
    <li>filename encoded image loader</li>
    <li>Image cache plugins</li>
    <li>URL Loader loads into memory, and passes stream to level 2</li>
    <li>File loader creates file stream, and passes to level 2</li>
  </ol>
  </li>
  <li>Second List takes stream and filename.
  <ol>
    <li>Simple file format loaders.</li>
    <li>File format loader that then needs to load subsequent files</li>
  </ol>
  </li>
</ol>

<h3>Practical</h3>

<p>This is getting too messy. Instead we will start with a single list of loaders,
that will each get a chance to load an image based on a filepath. In all other
respects the loader should be like the vil loader. It should load an image view
by</p>

<ol>
  <li>Passing the filename (not open stream as in vil) to a sequence of loaders</li>
  <li>Each loader should attempt to determine relatively quickly if it can load
    the filename</li>
  <li>The actual filename(s) to be loaded can be inferred from the filename -
    they need not match precisely.</li>
  <li>As a loader attempts to read the file, it can abort at any time, by
    returning a null image_resource_sptr</li>
  <li>When all the image header details, etc have been read, the image loader
    will return a formed image_resource</li>
  <li>The vil3d_load function (or client) can then call the resource's get_view()
    to read the image.</li>
</ol>

<h4>Use cases</h4>
<p> That should allow the following use cases.</p>
<ol>
  <li>Filename is in the filesystem namespace. Fileformat identified by file contents.</li>
  <li>Filename implies a set of files. Files are in the filesystem. The
existence of the files triggers full attempt to load files. The file
contents confirm the filetype.</li>
  <li>Filename describes image in entirety</li>
</ol>

<h2>How to save files in vil3d</h2>
<p>No file saving routines have been written, but place holders for various
parts of the saving system are in place.<br>
I recommend that you follow the pattern used by vil. It may be complicated, but
it had many advantages in dealing with large files, and header information. As
with the loader, vil3d saver should pass around filenames to image_format::make_output_image(),
so that multiple slice filenames, etc. can be inferred.</p>
<p>Ian Scott.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>

</body></html>
